1. Field of the Invention
The present invention relates to a database management system based on the client/server architecture, and more particularly to a database management system of this kind constructed such that machines for sending a request for processing to a database are different from the machine that actually executes the requested processing.
2. Description of the Related Art
Conventionally, in the database management system based on the client/server architecture, the server software operates on a server machine to execute processing of the database, while the client software operates on a client machine on a network to which the server machine is connected. The network conveys requests for processing to the server and the results of the requests to the client.
In using a database managed by the database management system operating on a network to which the client machines and the server machine are connected, in general, when the client makes a request for access to the database, the server creates an executing entity which executes the request from the client and sends back the results of the processing of the request to the client. When the processing of the request is terminated, the executing entity is terminated or deleted. When the executing entity is created, resources of the server are allocated to the executing entity, and when the executing entity is terminated, the resources allocated to the executing entity are relinquished as well. These resources include memory in the server machine, a transaction lock controlled by the database management system for exclusive control, a memory area in a secondary storage medium for carrying out sorting operations, etc.
The machines based on the client-server architecture exist in operating environments different from each other. These machines use, as their operating systems, Windows 95 and Windows NT (Windows 95 and Windows NT are registered trademarks of Microsoft Corporation in the United States and other countries), or UNIX (developed and licensed by UNIX System Laboratories) -based operating systems. In the described configuration, during communications between a client machine and the server machine, the client machine may crash or the power thereof may be unexpectedly turned off. When one of these situations occurs after a request for access to the database is sent from the client machine to the server machine, information on the down conditions of the client machine is not sent to the server machine. The result is that the server carries out the processing in response to the request for access to the database, but the machine to which the results should be returned is no longer connected to the network so that the executing entity started in response to the request for access to the database continues to run and the resources allocated thereto remain unavailable on the server machine. As a result, when another client sends a request for access to the database to the server machine, there can be a case in which there are no resources which can be allocated to an executing entity newly created in response to the request, so that this client may be compelled to wait. Further, the client machine can go down not only when the power is turned off, but also when the reset button of the client machine is depressed.
To eliminate the inefficiency of the resources remaining allocated to an executing entity created for a client machine that made a request for access to the database but that went down thereafter, two methods are typically employed:
FIG. 5 is a block diagram schematically showing the arrangement of a conventional database management system. In FIG. 5, a client machine 101 and a server machine 111 are connected to a network 120, and the network 120 has an operator terminal 130 connected thereto and used in server administration. It is now assumed that in the client machine 101, a client process 102 has been started, while a database management system (DBMS) server process 112 has been started in the server machine 111. The database management system server process 112 has created a database (DB) access executing entity 113 in response to a request for access to the database from the client process 102, and resources 114 have been allocated to the database access executing entity 113. Further, the server machine 111 has a recovery command 115 provided therein for terminating the executing entity.
When the operator of the server monitors requests from the client, and if he recognizes that the power of the client machine 101 on which the client process 102 operates is in the OFF state due to some unknown cause during the access of the client process 102 to the database, he executes the recovery command 115 on the server machine via the operator terminal 130. The recovery command 115 terminates the database access executing entity 113 created in response to the request for access to the database from the client process 102 and relinquishes the resources 114 allocated to the database access executing entity 113 for the processing of the request. This makes these resources on the server machine 111 available for another client which makes a request for access to the database.
FIG. 6 is a block diagram schematically showing another example of construction of a conventional database management system. In FIG. 6, a client machine 101 and a server machine 141 are connected to a network 120. In the server machine 141, a database management system server process 142 operating thereon includes a database (DB) access executing entity 143, resources 144, and an executing entity control daemon 145 for controlling the database (DB) access executing entity 143. Further, the server machine 141 is capable of executing a network-monitoring function 146 provided by its operating system (OS).
When the client process 102 on the client machine 101 communicates with the database management system server process 142 on the server machine 141, both the machines are required to designate a port for sending and receiving messages between the two machines. In general, the combination of a port on one client machine 101 and a port on the server machine 141, combined with a physical medium for carrying out serial transfer of messages between the machines, is hereinafter called "a communication path". In one combination of one port of the client machine and one port of the server machine, there can exist a number of communication paths each of which can send and receive messages in parallel with another. "Socket" is one typical example of a communication path. Details of the "Socket" are described in literature "UNIX NETWORK PROCESSING," W. Richard Stevens, 1990 by Prentice Hall, Inc. A Simon & Schuster Company Englewood Cliffs, N.J. 07632.
Now, in order to make use of the network function of the operating system, the port via which communications are carried out is registered with the operating system. The network-monitoring function 146 of the operating system checks for a time during which communications are not being carried out, for each communication path, and if the communication path is not used for a predetermined time period, the communication path is canceled, and the process waiting to receive data via the communication path is notified of the cancellation of the communication path. The time period with reference to which the cancellation of each communication path is determined is set by the system administrator. When the executing entity control daemon 145 of the database management system server process 142 is notified of the cancellation of the communication path from its communications environment, it terminates the database access executing entity 143 which has been communicating via the communication path and keeping the resources 144 unavailable to other executing entities.
Thus, in the database management system which makes use of the clock function of the operating system for the network time-monitoring function, a predetermined monitoring time period is set and the network-monitoring function 146 of the operating system periodically checks to determine whether any communications were carried out within that time period. When the network-monitoring function 146 of the operating system detects that no communications were carried out over the predetermined time-monitoring period, it notifies the executing entity control daemon 145 of the cancellation of the communication path from the communications environment. It should be noted that if the predetermined monitoring time period is set to too short a time period, the overhead of the operating system is increased. To avoid this inconvenience, normally, it is set to a time period longer than two hours.
In the case where the executing entity termination function is provided on the server side, however, the server machine is required to constantly monitor whether any executing entity is running which is required to be terminated. If the power of the client machine is turned off when there is no operator monitoring the server, the resources allocated during extension of access to the database remain inaccessible on the server machine.
On the other hand, when the network-monitoring function of the operating system is utilized, it is difficult to set a reference time period with reference to which the state of no communications with a client is determined. More specifically, when the requests of clients impose heavy load on the server, it can take more than two hours to send back results of the processing requested by a client, which makes determining the proper reference time period largely dependent on the operating characteristics of the database, as well. Therefore, if communications paths on which no communications were carried out over the reference time period are all cancelled unconditionally, the problem of cancellation of communication paths which should not be cancelled may occur. Further, when the network time-monitoring function of the operating system is used, the overhead of the operating system becomes large since it must periodically monitor the system to determine whether communications are being carried out or not. Therefore, the reference time period is normally set to two hours or longer than two hours by increments of one hour. However, once the client machine goes down, the transaction is locked at least until the time-monitoring function is next initiated. As a result, processing requests for access to the database from other clients may be delayed during this time.